這篇不在原本的三十篇大綱裡。

它是這週順稿時長出來的：寫 Day 10 的時候，我自問了一句「50KB 到底算不算大」。為了回答，我把整個工作區從頭量了一遍——數字出來的那一刻，這篇就把原定的題目擠掉了。

先給數字（寫這篇當天量的，之後會變）：

整個 workspace：2,070 個 Markdown、8.0 MB。

八千多 KB。Day 10 才講完「單檔 50KB 就要拉警報」，自家工作區是那條線的一百六十倍。這一週寫的全是怎麼治理記憶——那治理系統自己，誰來治理？

今天講體檢的結果。兩種病，療法完全不同。

第一種病：肥大——量完才知道，大頭是健康的

先把 8MB 拆開：

看出來了嗎？8MB 裡讓人心驚的部分，其實是健康的。冷歸檔大，代表歸檔機制半年來一直在工作；產出物大，代表系統真的有在產出。會咬人的只有熱集合那 100KB——它是 Day 10 講的「每次醒來要繳的固定稅」，而且每個角色每天要繳幾十次。

真正的異常，藏在兩個「最不該胖的檔」裡：

• 待辦檔 41KB——比長期記憶檔還肥三倍。待辦清單會肥只有一種可能：完成的項目堆在原地，沒人收走。而它每次醒來都被全文重讀——用 Day 10 的話說，我每天在為「早就做完的事」繳稅。
• 某個角色的常駐三件套 27KB——其他角色都在 2–11KB 之間。掀開看，是「當下專案的細節脈絡」爬進了常駐層：該放專案檔的內容，混進了每次醒來都要讀的人格層。

教訓一句話：肥大要先分冷熱。冷倉庫大是歷史，熱集合大是稅——而異常通常不在最大的檔，在「最不該胖的檔」。

第二種病：漂移——同一個事實，住在兩個檔裡

比肥大更麻煩的是第二種病，因為它沒有警戒線可設。

順稿這幾天，我在自家文件裡連抓到四例：

1. 行為協定檔裡寫死的排程數量，跟實況差了快一倍——同一天抓到兩處。
2. 這個連載自己的底稿，每篇字數對照表早就過期——我一邊改稿一邊查表，查到的全是舊值。
3. 連你正在讀的這個系列自己也中招——我為連載寫的發布登記工具，把七篇還沒發布的文章標成了「已發布」。「以為發了其實沒發」是三十天連載最危險的失格方式，而差點送我上路的是我自己寫的工具。
4. 同一個投資觀察門檻，住在三個檔案裡——改了一個，另外兩個繼續拿舊值發警報。

四例長相不同，病根同一個：

同一個事實有兩份以上的副本，其中必有一份正在腐化。

這不是紀律問題——你不可能記得每個數字住在幾個地方——是結構問題。結構問題用「以後小心」來修，就是修不好。

解法是一座階梯——而且是撞出來的，不是設計出來的

回頭看，這半年系統其實已經演化出一套對付漂移的階梯——只是散落各處，撞一次長一級：

**第一級：會變的數字，不寫進散文。**排程有幾個、檔案有多大，文件裡不寫死數字，只寫「去哪查」。權威永遠指向活的來源（排程表本身、量測腳本的輸出）。第 1 例修完之後，那份文件現在開頭就是一句「本檔不記數量，權威看實況」。

**第二級：非要快照，就標日期和權威來源。**有些對照表就是得存在。那就讓每份快照自帶「這是某天的照片，不是現況」——這篇開頭那句「寫這篇當天量的，之後會變」，就是在做這件事。

第三級：對帳器——一致性靠機器對帳，不靠人記得。發布登記那個坑，最後的修法不是「以後小心」，是讓工具替每篇文章存一枚內容指紋（雜湊值）：原稿一改、登記的指紋對不上，狀態自動翻紅。另有一支每週跑的對帳腳本，把「文件說的」跟「系統跑的」對一遍，對不上就報。

第四級：人工，只管前三級蓋不到的——截圖裡的隱私、語意層的錯、還有 Day 11 講過的：意圖。

順序很重要：**能不重複就不重複；必須重複就標時效；標了時效就派機器對帳；機器管不到的才輪到人。**大多數人（包括半年前的我）直接跳到第四級硬扛，然後怪自己不夠自律。

盤點：還有三個洞

照這個系列的慣例，講完做到的，也要講還沒做到的：

• 熱集合沒有預算。單檔有 50KB 紅線，但「每次醒來總共讀多少」沒有上限。而且超標該做的是精煉改寫，不是歸檔——歸檔治冷、精煉治熱，而精煉到今天還是純人工。
• **「已知多源」的事實沒有收斂登記。**門檻住三個檔那種病，修法是收斂成單源、其他地方只放指標——但前提是先有一張「哪些事實是多源的」清單。現在沒有，都是撞到才知道。
• **文件對文件的對帳還沒蓋到。**這裡有個反直覺的坑：別做泛用檢查。拿關鍵字全域掃描，會把「討論問題的內容」當成問題本身（我踩過）——只對「登記過的事實對」對帳，才不會被誤報淹死。

小結

• 肥大分冷熱：冷倉庫大是歷史，熱集合大是每次醒來的稅；異常藏在「最不該胖的檔」（待辦、常駐人格層）
• 漂移的病根：同一事實多份副本，必有一份在腐化——是結構問題，不是紀律問題
• 治理階梯：單一事實來源 → 帶時效的快照 → 對帳器 → 人工只管剩下的——能不重複就不重複
• 三個洞：熱集合預算、多源登記、文件對帳——治理系統的治理，也是做不完的事

治理檔案這麼囉嗦，你大概想問：乾脆上資料庫不就好了？明天正面回答這一題——我的 AI 沒有資料庫，這個聽起來很蠢的決定，用了半年之後我怎麼看。

🔑 這篇的關鍵字
冷熱集合（hot set / cold archive）——冷倉庫大是歷史，熱集合大是稅 · 文件漂移（doc drift）：同一事實多副本必腐化 · 治理階梯：單一事實來源（SSOT）→ 帶時效的快照 → 對帳器（reconciler）→ 人工 · 內容指紋（hash）偵測原稿與發布版漂移 · 別做泛用關鍵字掃描——只對登記過的事實對對帳

我是一名金融業資訊工程師，這是我半年來在家自架 AI Agent 系統的實錄。